CloudWatch Alarms를 설정하고 EC2 사용률에 대한 경보를 이메일로 받아보기

안녕하세요 클래스메소드 김재욱(Kim Jaewook) 입니다. 이번에는 CloudWatch Alarms를 설정하고 EC2 사용률에 대한 경보를 이메일로 받아보는 과정을 정리해 봤습니다.

CloudFormation으로 CloudWatch Alarms를 설정하는 방법은 아래 블로그를 참고해 주세요.

 

SNS Topic 생성

먼저 CloudWatch Alarms를 설정하기에 앞서 SNS Topic을 생성 해야합니다.

Amazon SNS로 들어온 다음「주제 생성」버튼을 클릭합니다.

어디까지나 테스트용이기 때문에 별다른 설정을 할 필요 없이「표준」을 선택한 다음 이름을 입력하고 SNS Topic 생성을 끝마칩니다.

기타, SNS Topic에 대한 내용은 아래 링크를 참고해 주세요.

 

Amazon SNS Topic 생성이 끝났다면「구독」으로 들어간 다음「구독 생성」버튼을 클릭합니다.

주제 ARN은 조금 전 생성한 Amazon SNS topic을 선택합니다.

이메일로 알람을 받을 예정이기 때문에 프로토콜은 이메일을 선택합니다.

마지막으로 엔드포인트는 알람을 받을 이메일 주소를 적습니다.

보다 상세한 내용은 아래 링크를 참고해 주세요.

 

설정한 이메일 주소로 들어가 보면 다음과 같은 메일이 온 것을 확인할 수 있습니다.

「Confirm subscription」을 클릭합니다.

구독이 성공적으로 완료 되었다는 팝업 창이 나타납니다.

다시 구독 상태를 확인해 보면「확인됨」으로 바뀐 것을 확인할 수 있습니다.

CloudFormation으로 Amazon SNS를 설정하는 방법에 대해서는 아래 블로그를 참고해 주세요.

 

CloudWatch Alarms 설정

이제 CloudWatch Alarms를 설정하기 위해 이제 CloudWatch-> 경보로 들어온 다음「경보 생성」버튼을 클릭합니다.

「지표 선택」을 클릭합니다.

EC2 인스턴스의 CPU 사용률만 체크할 생각이기 때문에 CPUUtilization을 선택하고「지표 선택」을 클릭합니다.

측정치	설명
CPUUtilization	인스턴스에서 현재 사용 중인 할당된 EC2 컴퓨팅 유닛(ECU)의 비율(%)입니다.이 지표는 선택한 인스턴스에서 애플리케이션을 실행하는 데 필요한 처리 능력을 식별합니다. 인스턴스 유형에 따라 인스턴스에 전체 프로세스 코어가 할당되지 않았을 때 운영 체제의 도구에서 비율이 CloudWatch와 다르게 표시할 수 있습니다.   단위: 백분율
DiskReadOps	지정된 시간 내에 인스턴스에 사용할 수 있는 모든 인스턴스 스토어 볼륨에서 읽기 작업 완료. 기간의 평균 IOPS(초당 I/O 작업 수)를 계산하려면 기간의 총 작업 수를 해당 기간의 초 수로 나누세요. 인스턴스 스토어 볼륨이 없으면 값이 0이거나 측정치가 보고되지 않습니다.   단위: 개수
DiskWriteOps	지정된 시간 내에 인스턴스에 사용할 수 있는 모든 인스턴스 스토어 볼륨에 대한 쓰기 작업 완료. 기간의 평균 IOPS(초당 I/O 작업 수)를 계산하려면 기간의 총 작업 수를 해당 기간의 초 수로 나누세요. 인스턴스 스토어 볼륨이 없으면 값이 0이거나 측정치가 보고되지 않습니다.   단위: 개수
DiskReadBytes	인스턴스에 사용할 수 있는 모든 인스턴스 스토어 볼륨에서 읽은 바이트 수. 이 지표는 애플리케이션이 인스턴스의 하드 디스크에서 읽는 데이터 볼륨을 결정하는 데 사용됩니다. 이를 사용하여 애플리케이션의 속도를 결정할 수 있습니다. 보고된 숫자는 해당 기간에 수신된 바이트 수입니다. 기본(5분) 모니터링을 사용하는 경우, 이 숫자를 300으로 나누어 바이트/초를 찾을 수 있습니다. 세부(1분) 모니터링의 경우 60으로 나눕니다. 인스턴스 스토어 볼륨이 없으면 값이 0이거나 측정치가 보고되지 않습니다.   단위: 바이트
DiskWriteBytes	인스턴스에 사용할 수 있는 모든 인스턴스 스토어 볼륨에 쓴 바이트 수. 이 지표는 애플리케이션이 인스턴스의 하드 디스크에 쓰는 데이터 볼륨을 결정하는 데 사용됩니다. 이를 사용하여 애플리케이션의 속도를 결정할 수 있습니다. 보고된 숫자는 해당 기간에 수신된 바이트 수입니다. 기본(5분) 모니터링을 사용하는 경우, 이 숫자를 300으로 나누어 바이트/초를 찾을 수 있습니다. 세부(1분) 모니터링의 경우 60으로 나눕니다. 인스턴스 스토어 볼륨이 없으면 값이 0이거나 측정치가 보고되지 않습니다.   단위: 바이트
MetadataNoToken	토큰을 사용하지 않는 방법으로 인스턴스 메타데이터 서비스에 성공적으로 액세스한 횟수입니다. 이 메트릭은 인스턴스 메타데이터 서비스 버전 1을 사용 중인 인스턴스 메타데이터에 토큰을 사용하지 않고 액세스하는 프로세스가 있는지 확인하는 데 사용됩니다. 모든 요청이 토큰 지원 세션을 사용하는 경우(예: 인스턴스 메타데이터 서비스 버전 2) 값은 0입니다. 자세한 내용은 인스턴스 메타데이터 서비스 버전 2 사용으로 전환 섹션을 참조하세요.   단위: 개수
NetworkIn	모든 네트워크 인터페이스에서 인스턴스가 받은 바이트 수입니다. 이 측정치는 단일 인스턴스로 들어오는 네트워크 트래픽의 볼륨을 식별합니다. 보고된 숫자는 해당 기간에 수신된 바이트 수입니다. 기본(5분) 모니터링을 사용하고 통계가 합계인 경우, 이 숫자를 300으로 나누어 바이트/초를 찾을 수 있습니다. 세부(1분) 모니터링으로 설정되어 있고 통계가 합계인 경우 60으로 나눕니다.   단위: 바이트
NetworkOut	모든 네트워크 인터페이스에서 인스턴스가 보낸 바이트 수입니다. 이 측정치는 단일 인스턴스에서 나가는 네트워크 트래픽의 볼륨을 식별합니다. 보고된 숫자는 해당 기간에 전송된 바이트 수입니다. 기본(5분) 모니터링을 사용하고 통계가 합계인 경우, 이 숫자를 300으로 나누어 바이트/초를 찾을 수 있습니다. 세부(1분) 모니터링으로 설정되어 있고 통계가 합계인 경우 60으로 나눕니다.   단위: 바이트
NetworkPacketsIn	모든 네트워크 인터페이스에서 인스턴스가 받은 패킷 수입니다. 이 지표는 단일 인스턴스에서 수신 트래픽의 볼륨을 패킷 수 기준으로 식별합니다. 이 지표는 기본 모니터링에만 사용할 수 있습니다(5분간). 인스턴스가 수신한 PPS(패킷/초) 수를 계산하려면 이 수를 300으로 나눕니다.   단위: 개수
NetworkPacketsOut	모든 네트워크 인터페이스에서 인스턴스가 보낸 패킷 수입니다. 이 지표는 단일 인스턴스에서 발신 트래픽의 볼륨을 패킷 수 기준으로 식별합니다. 이 지표는 기본 모니터링에만 사용할 수 있습니다(5분간). 인스턴스가 5분 동안 전송한 PPS(패킷/초) 수를 계산하려면 통계 값 합계를 300으로 나눕니다.   단위: 개수

인스턴스 지표에 대한 내용은 다음과 같습니다.

보다 상세한 인스턴스에 사용 가능한 CloudWatch 지표에 대해서는 아래 링크를 참고해 주세요.

 

1분 동안의 평균 EC2 인스턴스의 CPU 사용률을 그래프로 나타냅니다.

정적을 선택하고, EC2 인스턴스의 1분 CPU 사용률의 임계값을 40%로 입력합니다.

정적과 이상 탐지에 대한 상세한 설명은 아래 링크를 참고해 주세요.

 

현재 CloudWatch Alarms의 상태가 경보 상태일 경우 선택한 이메일 주소로 알람이 가도록 트리거를 설정합니다.

마지막으로「경보 이름」을 입력하고 CloudWatch Alarms 생성을 끝마칩니다.

CloudWatch로 들어와 보면 정상적으로 생성된 것을 확인할 수 있습니다.

CloudWatch Alarms를 이제 막 생성 한 경우「데이터 부족」으로 나타나기 때문에 조금 기다려 보면 정상으로 바뀌게 됩니다.

혹은 지표에 데이터가 부족해서「데이터 부족」이라고 나타나는 경우도 있습니다.

상세한 내용은 아래 링크를 참고해 주세요.

 

CloudWatch Alarms 테스트

sudo amazon-linux-extras install epel -y
sudo yum install stress -y
sudo stress --cpu 1 --timeout 600

강제로 EC2 인스턴스의 CPU 사용률을 올리기 위해 stress를 사용합니다.

조금 기다려 보면 설정한 이메일로 알람이 오는 것을 확인할 수 있습니다.

CloudWatch에서 확인해 보면 CPU 사용률이 40%를 넘겼고, 경보 상태로 바뀐 것을 확인할 수 있습니다.

본 블로그 게시글을 읽고 궁금한 사항이 있으신 분들은 [email protected]로 보내주시면 감사하겠습니다.